Historically, a bank teller's interaction with customers and the bank's internal systems have been manually organized on a transaction by transaction basis with little to no capability of linking the information regarding the transaction with the paper(s) which constitute the transaction.
Some prior art teller systems maintained an electronic journal which allows the teller to perform limited research and allows the teller to reverse transactions selected from the electronic journal in the case where an error was actually discovered. However, this type of electronic journal is limited in its applicability as it is simply a sequential list of transactions performed at the bank. Furthermore, the electronic journal of the prior art has limited detail regarding transactions and must be supplemented by a continuous paper tape printed out at each teller system. Given the limited amount of information gathered at the teller workstation, the prior art methods and systems for back office processing were very labor and machine intensive. The term “back office” is well known to those skilled in the art and relates to the facility in the back which performs the processing for the bank, e.g. posting of transactions, clearing of checks, statement generation . . . . Each branch of the bank forwards all of the documents (e.g., checks, deposits slips . . . ) to the back office at the end of the day for processing. Back office processing for banking transactions includes for example, posting of transactions, statement processing, proof of deposit processing, end of day confirmation, account reconciliation and archiving. Until recently, most of the capture of data from the paper representing the transactions (e.g., checks) was done manually at the back office. For example, an operator would physically look at the check and enter the dollar amount written on the check into a record in the bank's database used for tracking checks. As larger banks process huge volumes of checks, each operator in the back office was responsible for data entry for thousands of checks per day. The shear volume and repetitiveness of this process naturally led to errors in the data processing. Recently, systems have been developed which optically scan the financial documents data and use character recognition to capture the data previously captured by human operators (e.g., the amount written on a check). FIG. 1 illustrates such a prior art system and method of back office processing. Typically at the end of the day, each branch of the bank forwards all of the paper 10 associated with the day's transactions (e.g., checks, deposit slips . . . ) to a central location.
The first process undertaken at the back office is to capture both images of the paper (front and back) and the Magnetic Ink Character Recognition (MICR) data contained on the paper. Module 15, Check Processing Control System (CPCS) Prime Capture, accomplishes both of these functions using conventional image enabled sorters, optical readers and MICR readers. The image data of the two sides of each of the papers 10 is stored in an image archive database 20, while the MICR data read from the paper is stored in a CPCS database 25. Once the image and MICR data have been captured by the CPCS Prime Capture 15, a Character Recognition Engine 30 analyzes the captured images in order to determine the amount of the transaction. If the Character Recognition Engine 30 successfully reads the amount of the transaction, the amount is used to update the record for that transaction in the CPCS database 25. Typically the Character Recognition Engine 30 is able to interpret the amount on approximately 60% of the transactions with a 2% error rate.
If the MICRline data on the paper document is read incorrectly, in the MICRline Data Completion module 35, an operator looks at the image of the document and manually completes the MICRline data in the transaction record for the document. If the Character Recognition Engine 30 fails to capture the amount of the transaction, in the Amount Key Entry module an operator manually read the image of the check from the image database 20 and inputs the amount into the transaction record contained in the CPCS database. If the character recognition for the amount on a deposit slip does not reconcile with the sum of the amount character recognized from the checks included on the deposit slip, the transaction balanced in the Deposit Balancing 45 module.
In Deposit Balancing 45, the amount listed on a deposit slip is compared with the total of the amounts of the checks associated with the deposit slip. If these two totals match, the deposit is considered balanced. If the totals do not match, an operator has to manually review the images of the deposit slip and the associated checks in order to determine and correct the error. Errors could occur in any number of areas such as incorrect character recognition by the Character Recognition engine or incorrect human input in the Amount Key Entry process 40.
As described above, the conventional back office processing of financial documents from the branches of the bank are very labor intensive and error prone. Even with the above described automation aids, the process is still very labor and machine intensive and still produces errors which can only be resolved by human intervention.